Systems and methods for placing virtual serving gateways for mobility management

ABSTRACT

Methods and systems for determining placement of a virtual serving gateway. The method includes obtaining a set of input information. The input information includes network information and configuration information providing one or more parameters for placing the virtual serving gateway, and includes at least one mobility insensitivity criterion. Placement of the virtual serving gateway at one or more physical hosts is determined in accordance with the network information and the configuration information. The virtual serving gateway is distributively placeable across physical hosts. A set of output information is generated. The output information includes information identifying placement of the virtual serving gateway at the physical hosts, and a hosting percentage for each physical host.

CROSS REFERENCE TO RELATED APPLICATIONS

The present disclosure is a continuation of U.S. patent application Ser.No. 15/243,486 issued as U.S. Pat. No. 9,832,657, which is acontinuation of U.S. patent application Ser. No. 14/561,805, filed Dec.5, 2014 and now issued as U.S. Pat. No. 9,445,279, the entirety of bothof which is hereby incorporated by reference.

FIELD

The present disclosure relates to mobile networks. In particular, thepresent disclosure relates to systems and methods for placing virtualserving gateways in a virtual network for mobility management.

BACKGROUND

In a wireless network, the geographical location of wireless userequipment (UE) may change over time. The physical path travelled by theUE over time may correspond to changes in the network links used by theUE, for example from one access point to another access point. The pathtravelled by the UE may also correspond to variations in link quality,for example as the UE enters and exits a tunnel or a building. Thismeans that data to and from the UE must be sent on a logical paththrough the network that is dynamic and potentially unstable. This canresult in complications for traffic engineering.

SUMMARY

In some examples, the present disclosure provides a method fordetermining placement of a virtual serving gateway. The method mayinclude obtaining a set of input information. The input information mayinclude network information providing information about a physicalnetwork for mobile communications by a mobile device; and configurationinformation providing one or more parameters for placing the virtualserving gateway, including at least one mobility insensitivitycriterion. The method may also include determining placement of thevirtual serving gateway at one or more physical hosts in the physicalnetwork in accordance with the network information and the configurationinformation. The virtual serving gateway may be distributively placeableacross one or more physical hosts. A set of output information may begenerated, including: information identifying placement of the virtualserving gateway at the one or more physical hosts; and a respectivehosting percentage for each physical host.

In some examples, the present disclosure provides a system for placing avirtual serving gateway. The system may include a processing deviceconfigured to cause the system to obtain a set of input information. Theinput information may include network information providing informationabout a physical network for mobile communications by a mobile device;and configuration information providing one or more parameters forplacing the virtual serving gateway, including at least one mobilityinsensitivity criterion. The system may also be caused to determineplacement of the virtual serving gateway at one or more physical hostsin the physical network in accordance with the network information andthe configuration information. The virtual serving gateway may bedistributively placeable across one or more physical hosts. A set ofoutput information may be generated, including: information identifyingplacement of the virtual serving gateway at the one or more physicalhosts; and a respective hosting percentage for each physical host.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanyingdrawings which show example embodiments of the present application, andin which:

FIG. 1 is a schematic diagram of an example logical architecture for anetwork;

FIG. 2 is a schematic diagram of an example software-defined topologysystem, in communication with a software-defined network controller;

FIG. 3 is a schematic diagram of an example software-defined networkcontroller, in communication with a software-defined topology system;

FIG. 4 is a schematic diagram of an example computing system suitablefor implementing the present disclosure;

FIG. 5 is a schematic diagram of an example virtual network topology formobility management;

FIG. 6 is a flowchart illustrating an example method for placing virtualserving gateways for mobility management; and

FIG. 7 is a diagram illustrating an example determination of mobilitysensitivity.

Similar reference numerals may have been used in different figures todenote similar components.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Software-defined networking (SDN) is an architectural framework forcreating intelligent programmable networks, where network trafficmanagement and network traffic forwarding are separated into the controlplane and the data plane, respectively. In SDN, network control iscentralized and the underlying network infrastructure is abstracted fromthe application.

A software-defined topology (SDT) may be formed, in accordance with thepresent disclosure for example, and the SDT may be used with SDN andsoftware-defined protocol (SDP) to create a virtual network (VN).Network traffic may be managed at a controller in the control plane overthe VN, without requiring the controller to directly manage the physicalnodes of the network. A VN may be a per-user network, meaning that theVN may be a collection of resources virtualized to service a particularuser (e.g., a particular user equipment (UE) or non-mobile terminal).The SDT may be formed based on customer information and providerinformation. Customers may include users of one or more services (e.g.,via the UE or terminal). Providers may include service providers, VNoperators, and/or other providers of services over the network.

In the SDN control plane, one or more SDN controllers may manage networkresources and control network traffic globally. For simplicity, thepresent disclosure will refer to the SDN controller in the singular,however it should be understood that there may be more than one SDNcontroller in accordance with some examples of the present disclosure.The SDN controller may solve a traffic engineering (TE) problem based onthe status information of individual network elements and overalltraffic requirements. Generally, TE may jointly determine for eachtraffic flow the routing paths and resource allocation (also referred toas traffic splitting) along the paths with respect to the quality ofservice (QoS) requirements (e.g., rate demand) of individual flows andwith respect to resource constraints (e.g., link capacity) so that anetwork utility is maximized and satisfactory quality of experience(QoE) is delivered to users. The SDN controller provides controlinstructions to data plane hardware for optimizing the operation of theentire network, using a suitable inter-plane communication mechanism. Inthe data plane, flows are then split among their routing paths followingthe instructions.

Due to network and traffic dynamics, TE may be carried out at timeintervals, and its solution typically exhibits dynamics, such as routingdynamics and splitting dynamics. In cases where flow paths arepredetermined, TE optimization may be reduced to resource allocationamong flow paths. In this case, routing dynamics may be due to mobilityof UEs, while splitting dynamics may result from routing dynamics andtraffic distribution in the network.

UE mobility over the VN may present challenges for TE. For a highlymobile UE, the data path for routing data from a data source to the UEmay be highly time-varying and may result in unstable TE. Unstable TEthat is highly sensitive to UE mobility may consume a significantportion of resources (e.g., requiring large control overhead) and/orresult in degraded system performance.

Approaches to mobility management include centralized mobilitymanagement (CMM) and distributed mobility management (DMM). In CMM,mobility management functions are typically co-located in a core networknode. However, this may result in overloading of the core network nodeand/or inefficient routing of traffic. In DMM, different network nodesare typically set up as gateways to handle different mobility functions,which may help to address some of the issues of CMM. However, thereremains a need to determine how to locate the gateways at physicalnetwork nodes for data forwarding and processing. For example, differentnetwork nodes may have different cached contents and/or different dataprocessing capabilities, which may make the network nodes more or lesspreferred for hosting a gateway. In various examples, the presentdisclosure enables placement of virtual serving gateways at physicalhosts, while taking into account the data routing potential and dataprocessing capabilities of the physical hosts.

To assist in understanding the present disclosure, reference is firstmade to FIG. 1, showing an example logical architecture 100 for anetwork which may be used for communications with a mobile UE. Theexample architecture 100 may be used to implement SDN, using a SDT. TheSDT may cooperate with SDN to facilitate traffic control and/or trafficprocessing, by defining virtual serving gateways via which data arerouted to and from the UE, and by providing a virtual topology, asdiscussed further below.

Generally, a SDT may provide a framework for software-defined contentdelivery that may allow operators to define on-demand and servicespecific data plane architecture (also referred to as network topologyor logical topology) to help enable more efficient use of networkresources and/or help ensure quality of experience (QoE) and/or qualityof service (QoS) to users. The SDT may, for each application, service orper-user VN, determine an on-demand and customized data plane topology.The SDT may define the physical locations of logical network nodes forthe logical data plane, as well as the topology of the nodes in the dataplane topology. The SDT may also define service-specific oruser-specific data processing functionalities for logical nodes in thedata plane logical topology.

Generally, a logical node may be a software-defined entity implementedat a physical network node (also referred to as the physical host forthe logical node), may perform various functions and may take on variousroles within the network. For example, a logical node may be aservice-specific virtual serving gateway (v-s-SGW), a user-specificvirtual serving gateway (v-u-SGW), or a content container, among otherpossible roles.

The SDT typically determines the data plane logical topology for eachapplication, service, or per-user VN, based on requirements such as QoEand/or QoS. The SDT may also determine the data plane logical topologyaccording to the service level logical topology, service-function chainrequirements, service traffic characteristics, customer distribution,mobility speed prediction, and/or traffic load predictions, among otherparameters. The SDT may be adaptive to feedback from the SDN controller,as discussed further below, to enable adaptation to changes in trafficload, network node capabilities, and/or changes in the physical network,for example. The SDT may be managed by network providers, VN providersor other operators.

FIG. 1 shows the example network architecture 100 separating an examplenetwork (e.g., a mobile network) into a data plane 110, a control plane120 and a management plane 130. The data plane 110 may transport networktraffic among various network nodes and UEs (e.g., UEs to access points,access points to routers, and access points/routers to servers). Thecontrol plane 120 may perform TE and may transport control signals amongthe various network nodes. The management plane 130 may providemanagement and administrative functionalities for the network. The dataplane 110, the control plane 120 and the management plane 130 mayinterface with each other, to enable the functionalities of each plane.

The control plane 120 may provide an application programming interface(API) 122 to allow one or more applications 140 to access the controlplane 120. The control plane 120 may host various control blocks, suchas a SDT system 200 and SDN controller 300, and a SDP system 128, tocarry out the functionalities of the control plane 120. The SDT system200, SDN controller 300 and SDP system 128 may be implemented in one ormore shared or separate processing systems.

The management plane 130 may host various control blocks (e.g., softwaremodules) to carry out its functionalities. For example, the managementplane 130 may implement an infrastructure manager 132, a data analyzer134, a customer service manager 136 and/or a connectivity manager 138.Other functionalities may be provided by the management plane 130, suchas content service management, which may define content caches in aradio access network (RAN), may configure cache-capable network nodes,and may manage content forwarding.

The management plane 130 may access one or more databases, which may beincluded in the architecture 100, to carry out its functionalities.Example databases include a privacy network database 150, a customerservice information database 152, a customer device information database154, an infrastructure database 156 and an infrastructure abstractiondatabase 158. The privacy network database 150 may store topologyinformation, security information, information about node capabilitiesand/or information about node states. The customer service informationdatabase 152 may store authentication and security information relatedto customer devices (e.g., UEs). The customer device informationdatabase 154 may store information about capabilities, locations and/orstates of customer devices. The infrastructure database 156 may storeinformation about network topology, node capabilities and/or nodestates. The infrastructure abstraction database 158 may storeinformation about various infrastructure abstractions within thenetwork. There may be more or fewer databases than those described inthis example, and one or more of these example databases may be combinedas a single database.

FIG. 2 is a schematic diagram of an example system for placing virtualserving gateways and generating a logical topology for mobilitymanagement over a VN. The system may be the SDT system 200. The SDTsystem 200 may generally be responsible for customizing the logical dataplane topology for the VN. In the present disclosure, the logical dataplane topology for the VN will be generally referred to as the VNtopology. The SDT system 200 may communicate with one or more networkcontrol components, such as the SDN controller 300 and the SDP system128. The SDT system 200 may cooperate with the SDN controller 300 tofacilitate traffic control and processing, for example as disclosedherein.

The SDT system 200 may store information used to determine placement ofvirtual serving gateways and generate a VN topology. In the exampleshown, the SDT system 200 stores network information and configurationinformation in respective network information database 205 andconfiguration information database 210. This information may be storedin a memory of the SDT system 200, for example, as discussed furtherbelow with respect to FIG. 4. The network information database 205 mayinclude information about the physical network (e.g., UE identificationand properties, UE traffic, network node properties, and/or virtualserving gateway candidates), discussed further below. The configurationinformation database 210 may include parameters used for placing virtualserving gateways and for generating a VN topology, such as costmeasures, mobility sensitivity requirements and scope of interest, asdiscussed further below. The network information and the configurationinformation may be received as input from one or more external sources(e.g., from the SDN controller 300 or from an operator). In someexamples, the network information and/or the configuration informationmay not be stored by the SDT system 200, but may instead be received orretrieved from an external source (e.g., one or more external databases)and may be discarded after use, in which case the network informationdatabase 205 and/or the configuration information database 210 may beomitted from the SDT system 200. In some examples, the networkinformation database 205 and the configuration information database 210may be replaced by a single database of input information, or with otherdatabase(s).

A gateway placement module 215 may obtain network information andconfiguration information (e.g., from the network information database205 and the configuration information database 210, or from an externalsource such as the SDN controller 300) as input to place one or morevirtual serving gateways at one or more physical hosts. The gatewayplacement module 215 may determine placement of the virtual servinggateway(s) using an optimization process, such as in the exampledescribed below. Although the term “optimization” is used, it should beunderstood that this refers to a process in which the virtual servinggateway(s) is(are) placed at physical host(s) to meet certain criteria(e.g., as specified in the configuration information), and may not bestrictly “optimal”. For example, there may be trade-offs and/orestimation involved, and some criteria may be prioritized over othercriteria (e.g., based on selection by an operator).

The gateway placement module 215 may output information definingplacement of the virtual serving gateway(s) at one or more physicalhosts, which information may be stored in a gateway placement database220 in a memory of the SDT system 200. The gateway placement informationmay include, for example, selection of physical hosts for virtualserving gateways and share of gateway traffic per physical host.

A topology generation module 225 may obtain network information andconfiguration information (e.g., from the network information database205 and the configuration information database 210, or from an externalsource such as the SDN controller 300), as well as the determinedplacement of virtual serving gateway(s) (e.g., from the gatewayplacement module 215 or from the gateway placement database 220) asinput to generate a VN topology. The topology generation module 225 maygenerate a VN topology using a suitable optimization process.

The topology generation module 225 may output information about thegenerated VN topology, which information may be stored in a VN topologydatabase 230 in a memory of the SDT system 200. The VN topologyinformation may include, for example a network hierarchy (in exampleswhere a hierarchical topology is used) and/or links between logicalnodes at the same level (e.g., for a mesh topology).

The SDT system 200 may provide the VN topology information and thegateway placement information to the SDN controller 300, through wiredor wireless communication.

In some examples, the gateway placement database 220 may be omitted,such as where the gateway placement module 215 provides output directlyto the topology generation module 225 and to the SDN controller 300,without storing the gateway placement information within the SDT system200. Instead, the gateway placement information may be discarded afteruse, or may be stored externally to the SDT system 200 (e.g., within theSDN controller 300 or in another external database).

In some examples, the VN topology database 230 may be omitted, such aswhere the topology generation module 225 provides output directly to theSDN controller 300, without storing the VN topology information withinthe SDT system 200. Instead, the VN topology information may be storedexternally to the SDT system 200 (e.g., within the SDN controller 300 orin another external database).

In some examples, the SDT system 200 may also determine one or morefunctionalities to be provided by one or more virtual serving gateways(e.g., where there are no service restrictions at the physical host(s)of the virtual serving gateway(s)). The SDT system 200 may provideoutput information that defines functionality(ies) for specific virtualserving gateway(s) at specific physical host(s) to the SDP system 128.The SDP system 128 may then interact with hardware in the data plane 110to install/uninstall or otherwise enable/disable the definedfunctionality(ies) at the specified physical host(s). This may enablecustomizable or application-defined virtual serving gatewayfunctionalities. For example, application-defined functionalities mayinclude network coding function (e.g., fountain coding function), andvideo transcoding function in the case of video traffic.

The SDT system 200 may be physically hosted by one or more servers ofthe control plane 120.

FIG. 3 is a schematic diagram of an example SDN controller 300. The SDNcontroller may generally be responsible for customized resourceallocation. The SDN controller 300 may cooperate with the SDT system 200to facilitate traffic control and processing. For example, the SDNcontroller 300 may provide feedback to the SDT system 200, such asrequests to update or change the VN topology.

The SDN controller 300 may receive information from the SDT system 200defining a VN topology (e.g., including information defining placementof virtual serving gateway(s) at physical host(s) and links betweenvirtual serving gateway(s)), and may store the topology information in atopology database 305 in a memory of the SDN controller 300. The VNtopology information may be provided to a flow translator 310, which maytranslate the VN topology into individual flow segments for the purposeof TE. For example, a path through several levels of a hierarchicaltopology may be translated by the flow translator 310 into individualflow segments corresponding to each level. The flow segments from theflow translator 310 may be provided to a TE module 315 for trafficmanagement. The TE module 315 may perform traffic management on the flowsegments according to various suitable TE techniques. The SDN controller300 may implement a quality monitor 320 which may monitor the networktraffic for QoE and/or QoS. The SDN controller 300 may also implement anetwork monitor 325 which may monitor the network for network events,such as a significant change in the data plane topology (e.g.,addition/removal of a physical node, change in physical connectivitybetween network nodes), a significant change in the traffic flow, orother such network events.

The SDN controller 300 may provide feedback to the SDT system 200. Forexample, the SDN controller 300 may, through the TE module 315, thequality monitor 320 and/or the network monitor 325, request the SDTsystem 200 to update, change or otherwise generate a new VN topology.For example, the SDN controller 300 may request a new topology from theSDT system 200 when a significant change in the physical network isdetected (e.g., as detected by the network monitor 325), when asignificant change in traffic flow is detected (e.g., as detected by thenetwork monitor 325), or when QoE and/or QoS falls below a certainthreshold (e.g., as detected by the quality monitor 320).

FIG. 4 is a schematic diagram of an example processing system 400, whichmay be used to implement the methods and systems disclosed herein, suchas the example SDT system 200, the example SDN controller 300, and theexample methods described below. The SDT system 200 and the SDNcontroller 300 may be implemented on shared or separate processingsystems 400. In some examples, the SDT system 200 and/or the SDNcontroller 300 may be implemented by a plurality of processing systemsworking in parallel. The processing system 400 may be a server, forexample, or any suitable computing system. Other processing systemssuitable for implementing the present disclosure may be used, which mayinclude components different from those discussed below. Although FIG. 4shows a single instance of each component, there may be multipleinstances of each component in the processing system 400.

The processing system 400 may include one or more processing devices405, such as a processor, a microprocessor, an application-specificintegrated circuit (ASIC), a field-programmable gate array (FPGA), adedicated logic circuitry, or combinations thereof. The processingsystem 400 may also include one or more input/output (I/O) interfaces410, which may enable interfacing with one or more appropriate inputdevices 435 and/or output devices 440. The processing system 400 mayinclude one or more network interfaces 415 for wired or wirelesscommunication with a network (e.g., an intranet, the Internet, a P2Pnetwork, a WAN and/or a LAN). The network interface(s) 415 may includewired links (e.g., Ethernet cable) and/or wireless links forintra-network and/or inter-network communications. The networkinterface(s) 415 may provide wireless communication via one or moretransmitters or transmit antennas and one or more receivers or receiveantennas, for example. The processing system 400 may also include one ormore storage units 420, which may include a mass storage unit such as asolid state drive, a hard disk drive, a magnetic disk drive and/or anoptical disk drive.

The processing system 400 may include one or more memories 425, whichmay include a volatile or non-volatile memory (e.g., a flash memory, arandom access memory (RAM), and/or a read-only memory (ROM)). Thenon-transitory memory(ies) 425 may store instructions for execution bythe processing device(s) 405, to carry out the functions of the SDTsystem 200 and/or the SDN controller 300. Depending on whether theprocessing system 400 implements the SDT system 200 or the SDNcontroller 300 or both, the memory(ies) 425 may have tangibly storedthereon data and module(s) for implementing the functions of the SDTsystem 200 or the SDN controller 300 or both, as appropriate. Forexample, the memory(ies) 425 may include the network informationdatabase 205, the configuration information database 210, the gatewayplacement database 220 and/or the VN topology database 230, and modulessuch as the gateway placement module 215 and/or the topology generationmodule 225, as described above with respect to the example SDT system200 of FIG. 2. The memory(ies) 425 may additionally or alternativelyinclude the topology database 305, and modules such as the flowtranslator 310, TE module 315, quality monitor 320 and/or networkmonitor 325, as described above with respect to the example SDNcontroller 300 of FIG. 3. The memory(ies) 425 may include other softwareinstructions, such as for implementing an operating system and otherapplications/functions. In some examples, one or more data sets and/ormodule(s) may be provided by an external memory (e.g., an external drivein wired or wireless communication with the processing system 400) ormay be provided by a transitory or non-transitory computer-readablemedium. Examples of non-transitory computer readable media include aRAM, a ROM, an erasable programmable ROM (EPROM), an electricallyerasable programmable ROM (EEPROM), a flash memory, a CDROM, or otherportable memory storage.

There may be a bus 430 providing communication among components of theprocessing system 400, including the processing device(s) 405, I/Ointerface(s) 410, network interface(s) 415, storage unit(s) 420 and/ormemory(ies) 425. The bus 430 may be any suitable bus architectureincluding, for example, a memory bus, a peripheral bus or a video bus.

In FIG. 4, the input device(s) 435 (e.g., a keyboard, a mouse, amicrophone, a touchscreen, and/or a keypad) and output device(s) 440(e.g., a display, a speaker and/or a printer) are shown as external tothe processing system 400. In other examples, one or more of the inputdevice(s) 435 and/or the output device(s) 440 may be included as acomponent of the processing system 400.

FIG. 5 is a schematic diagram of an example VN topology suitable formobility management, which may be implemented using the networkarchitecture 100. In this example, the VN topology 500 is auser-specific topology for a particular UE 510 a, and includes one ormore virtual serving gateways 520, 525, and one or more data sources 530(e.g., a network gateway). Communications may include wiredcommunications and/or wireless communications (e.g., from a source 530to a virtual serving gateway 520, 525, from one virtual serving gateway525 to another virtual serving gateway 520, and/or from a virtualserving gateway 520 to the UE 510 a). Wireless communications may takeplace over any suitable network (e.g., an intranet, the Internet, apeer-to-peer (P2P) network, a wide area network (WAN), and/or a localarea network (LAN)), and may include short-range communications such asBluetooth communications, near field communications, cellularcommunications, and/or radiofrequency (RF) communications.

The UE 510 a may be any suitable user device. In the present disclosure,the UE 510 a may be any mobile communications device, such as a handheldtelephone, a cellular telephone, a laptop computer, a smartphone, or anyother suitable portable computing device. A user may use the UE 510 a toaccess one or more services and/or content via the VN topology 500, andmay use the UE 510 a for two-way communications via the VN topology 500.

In the VN topology 500, the UE 510 a is associated with a virtualserving gateway 520 by a logical path. Although the UE 510 a is shownassociated with a single virtual serving gateway 520, the UE 510 a maybe associated with two or more virtual serving gateways 520, for examplewhere different virtual serving gateways 520 provide different servicesto the UE 510 a. The VN topology 500 defines a logical path directlybetween the UE 510 a and the virtual serving gateway 520, however thisdirect logical path may be implemented by data transmission via one ormore access points and/or routers (not shown). Although the logical pathmay be considered to be bidirectional (i.e., serving both uplink anddownlink traffic), the physical implementation for transmission ofuplink data may be different than that for transmission of downlinkdata. The virtual serving gateway 520 may be physically hosted by one ormore physical network nodes (e.g., server(s)) and may migrate todifferent host(s) as the UE 510 a moves. The location of the UE 510 amay be tracked by any suitable mobility management technique.

A virtual serving gateway 520, 525 is a logical network node in the VNtopology 500. In a per-user VN, the virtual serving gateway 520, 525 istypically a v-u-SGW, which may provide traffic processingfunctionalities such as serving as an anchor point for data forwarding,providing network access protection, and providing privacy protection,among others. These functionalities may be defined by service customersand/or network operators, for example. A virtual serving gateway 520,525 may be embodied in a physical host, such as a server, and two ormore virtual serving gateways 520, 525 may be embodied in the samephysical host. In some examples, a virtual serving gateway 520, 525 maybe embodied in two or more physical hosts.

Where a virtual serving gateway 520, 525 is distributed across two ormore physical hosts, this may be referred to as the virtual servinggateway 520, 525 being fractionally hosted by each physical host (asopposed to integrally hosted in the case where the virtual servinggateway 520, 525 is hosted by a single physical host). A virtual servinggateway 520, 525 hosted by two or more physical hosts may be representedin the VN topology 500 as a single virtual node. For a single virtualserving gateway 520, 525 hosted by two or more hosts, the VN topology500 may specify the percentage of the gateway traffic forwarded by eachphysical host.

Different user-specific VN topologies, with different virtual servinggateways, may be defined for different UEs. The virtual serving gatewaysfor different user-specific VN topologies may share common physicalhosts in the physical network. The VN topology 500 may also be definedon a per-service basis, in which case a different VN topology may bedefined for different services provided to the same UE 510 a.Alternatively, the VN topology 500 may be defined for all servicesprovided to the UE 510 a, in which case the UE 510 a may be associatedwith different virtual serving gateways 520 (only one shown in FIG. 5)for providing different service(s).

Generally, a physical host (e.g., server) can host one or more virtualserving gateways that serve one or more UEs 510 in more than one VNtopology (as indicated by dashed lines). A physical host may hostdifferent fractions of different virtual serving gateways.

Traffic in the VN topology 500 may be controlled using a two-phaseapproach, namely the source-to-gateway phase and the gateway-to-UEphase. The source-to-gateway phase may be considered to be stable,because the virtual serving gateway 520 acts as a fixed destination fortraffic sent from the source 530 to the UE 510 a. Data may thus betransmitted along a stable data path from the source 530 to the virtualserving gateway 520 (and in some cases via one or more other virtualserving gateway 525, as discussed further below). The gateway-to-UEphase may be considered to be dynamic, because routing paths from thevirtual serving gateway 520 to the UE 510 a may change as the UE 510 amoves. Data may thus be transmitted along a dynamic data path from thevirtual serving gateway 520 to the mobile UE 510 a. The dynamic path maybe geographically local to the UE 510 a and may change in accordancewith the UE's 510 a movement. The stable path may be geographicallydistant from the UE 510 a and may be insensitive to the UE's 510 amobility. Generally, TE may be performed separately on each phase of thetraffic, and may be performed only on one phase or on both phases of thetraffic. For example, conventional TE may be performed on thesource-to-gateway phase, while TE with fountain coding may be performedon the gateway-to-UE phase.

Although FIG. 5 illustrates downlink traffic, the same or similar VNtopology 500 may be used for uplink traffic, and the data source 530 maybe alternatively or additionally a data sink. Uplink traffic maysimilarly involve two phases, namely the UE-to-gateway phase (with adynamic data path) and the gateway-to-sink phase (with a stable datapath), and TE may similarly be performed on both phases of the trafficor only on one phase.

The virtual serving gateway 520 may be placed at physical host(s) thatis(are) able to provide service functions and/or content to the UE 510 awithin a certain geographical area. In the example shown, the virtualserving gateway 520 is placed at physical host(s) serving thegeographical area A, which may not be a circular area as depicted.

In this example, the virtual serving gateway 520 is placed at physicalhost(s) with a consideration of UE mobility. In FIG. 5, the UE 510 a isat a first geographic location L1 at an initial time t1. At a latertime, the UE 510 a has moved to a second geographic location L2 at timet2. The placement of the virtual serving gateway 520 may be determinedto accommodate the mobility of the UE 510 a to a certain extent(referred to as the mobility insensitivity of the virtual servinggateway 520 and defined further below), by placing the virtual servinggateway 520 at physical host(s) whose service area covers the distancethe UE 510 a is expected to travel over a given period of time. Thus,the UE 510 a remains served by the virtual serving gateway 520 at thesame physical host(s) at both locations L1 and L2, such that the logicalpath between the UE 510 a and the virtual serving gateway 520 in the VNtopology 500 is unchanged, although the physical data path may havechanged (e.g., data communications may be routed through a different setof access points and/or routers). In this way, mobility of the UE 510 amay be “hidden” from the control plane 120.

The VN topology 500 may include inter-gateway links. For example, the VNtopology 500 may include hierarchical links in which a lower levelvirtual serving gateway 520 has a link with a higher level virtualserving gateway 525. This arrangement may enable service-functionchaining, for example. Other topology arrangements may be possible, suchas a mesh topology.

Each virtual serving gateway 520, 525 may have access to the contents ofrespective content caches 522 a, 522 b, 527 (e.g., implemented in thememory(ies) of respective server(s) hosting the virtual serving gateways520, 525). In the example shown, the virtual serving gateway 520 isembodied in two physical hosts (e.g., two servers) and has access to twocontent caches (522 a, 522 b (e.g., each content cache 522 a, 522 bbeing stored in a memory of a different physical host). The contentcaches 522 a, 522 b may store the same, different or overlappingcontent. The content caches 522 a, 522 b may store content that waspreviously provided to the same UE 510 a or to another UE 510. Byenabling different UEs 510 a, 510 in different per-user VNs to sharecontent in the content caches 522 a, 522 b, the present disclosure mayenable more efficient use of network resources and/or reduce networktraffic.

Generally, the VN topology 500 may be designed for more efficient andmore effective use of shared network resources, and to satisfy apredefined mobility insensitivity parameter. Given a set of physicalnetwork nodes that are suitable to be gateway host candidates, thechallenge may be how to best select the candidate(s) and place thevirtual serving gateway(s) 520, 525 at the host candidate(s).

For example, for a given UE 510 a, placement of the virtual servinggateway 520 at a physical host that has a shorter path from the source530 but a longer path from the UE 510 a may be less sensitive to UEmobility, but may result in less efficient use of network resources dueto traffic inflation (e.g., due to use of fountain coding). On the otherhand, placement of the virtual serving gateway 520 at a physical hostthat has a shorter path to the UE 510 a but a longer path from thesource 530 may be more sensitive to UE mobility and may require morefrequent relocation of the virtual serving gateway 520 to differenthost(s), unstable TE decisions, and increased control overhead.Generally, it may be more efficient to have a lesser number of hosts forthe virtual serving gateways 520, 525, in order to control operatingcosts. In some examples, where in-network content caching is availableat the physical host(s), it may also be more efficient for a physicalhost to host many virtual serving gateways for many UEs, in order toincrease the potential for content sharing.

In some examples, the present disclosure may enable the use of networkcoding at virtual serving gateways, to help improve efficiency of thenetwork. In network coding, data packets of one or more flows can becombined and forwarded to other network nodes. An example of networkcoding is the use of fountain codes (also known as rateless codes), inwhich data packets of one flow are combined to generate a set of manycoded data packets which are then transmitted to the UEs. The UEs mayrecover the original data from a subset of the coded data packets. Thismay be useful in situations where data channels for different UEs havedifferent error probabilities (e.g., in broadcast applications), inwhich cases it may be inefficient for each UE to send requests formissing data packets. The coded data packets may be generated at thedata source, however this may result in a significant amount ofredundant data packets being transmitted. In some examples of thepresent disclosure, the coded data packets may be generated at virtualserving gateways instead, which may help to reduce traffic redundancyand/or reduce transmission delay (since the virtual serving gateways arecloser to the UEs than the data source). In some examples, thecapability of a network node to carry out network coding may be takeninto account when determining the suitability of a physical network nodeto act as a physical host for a virtual serving gateway.

FIG. 6 is a flowchart of an example method for placing virtual servinggateways for mobility management. The example method 600 may beimplemented by the SDT system 200, using one or more suitable processingsystems 400. The example method 600 is described below for placement ofa virtual serving gateway for a given UE, however it should beunderstood that the method 600 may be carried out to place virtualserving gateways for different UEs jointly. The example method 600 maybe used to place virtual serving gateways for a per-service VN, as wellas for a VN that provides multiple services.

At 605, a trigger signal is received, indicating that new placement ofthe virtual serving gateway is needed. The trigger may be, for example,a timeout event (e.g., where the SDT system 200 implements a timer totrigger an update of gateway placement at set times, such as everyseveral minutes) and/or may be a signal transmitted to the SDT system200 from the SDN controller 300. For example, the SDN controller 300 maytransmit a signal to the SDT system 200 requesting a new VN topology andnew gateway placement:

in the event of QoS and/or QoE falling below a predetermined qualitythreshold;

in the event of a significant change to the network (e.g., change intraffic beyond a certain threshold, change in content access statistics,addition/removal of gateway candidate(s), change in gateway hostcapabilities, change in physical connectivity between network nodesincluding addition/removal of a physical link and/or increase/decreasein the capacity of a physical link);

in the event of gateway host overloading (e.g., due to arrival of a newUE, gateway traffic increasing above a certain threshold, resource usagebeyond a certain threshold, change in gateway host capabilities); and/or

in the event of network performance degradation (e.g., trafficcongestion at a given network node).

Where the trigger signal originates from the SDN controller 300, thetrigger signal may be generated by or in response to conditions detectedby the traffic engineering module 315, the quality monitor 320 and/orthe network monitor 325.

At 610, input information is obtained. The SDT system 200 may determineplacement of the virtual serving gateway based on a set of inputinformation including, for example, network information andconfiguration information.

Network information may include, among others:

UE properties information, such as location, speed/velocity,acceleration, and/or device category (e.g., maximum traffic ratesupported);

UE statistics information (which may include spatial and/or temporalstatistics), such as data rate (e.g., for downlink/uplinkcommunications, peak rate, mean rate, rate variance), traffic sources(e.g., Internet web addresses), traffic content (e.g., as identifiedusing a hash code based on content attributes or content labels), and/orcontent access (e.g., frequency and volume);

physical network topology information (which may include statisticaland/or instantaneous information), such as identification of physicalnodes, node properties (e.g., location, available/maximum storage space,available functions), identification of physical links, link properties(e.g., available/maximum capacity, buffer size), identification ofphysical connections of traffic sources to the network, and/orconnection properties (e.g. throughput, delay); and/or

control plane information, such as identification of connectivitybetween pairs of data plane hardware, and associated properties (e.g.,statistical throughput, operational cost, delay), identification ofgateway host candidates, and/or gateway host candidate properties (e.g.,upper/lower traffic load bounds, maximum/minimum UE count limits,traffic processing functions, traffic rate reduction/inflation factor,content indexing of cache contents).

Configuration information may include, among others:

desired mobility insensitivity;

definition of gateway-to-host association cost measure, such asstatistical cost (e.g., delay as cost, delay-jitter as cost, throughputas cost) and other cost measures (e.g., hop count, physical distance,operation cost);

information about network scope (e.g., geographic area of interest,services of interest);

customer/service information (e.g., customer/service identifier, servicerequirements such as service-function chaining requirements), which maybe specified by the customer, service provider and/or VN provider aspart of service requirements; and/or

definition of weight factors for content caching and/or content sharingconsiderations.

The present disclosure may use the terms network information andconfiguration information generally to refer to the input informationused to determine placement of gateways and to generate a VN topology.However, it should be understood that these are not strict categoricaldefinitions and other types of input information may be included. Forexample, some of the input information may also be referred to ascustomer information or service information.

This input information may be obtained from databases internal to theSDT system 200 (e.g., the network information database 205 and/orconfiguration information database 210), databases external to the SDTsystem 200, the SDN controller 300 and/or an operator. In some examples,such as where the trigger signal is received from the SDN controller300, at least a portion of the input information may be included withthe trigger signal at 605. For example, the SDN controller 300 maytransmit updated input information such as new configuration information(e.g., reduce/increase mobility insensitivity and/or reduce/increasecontent sharing consideration) to the SDT system 200, and this updatemay serve as the trigger signal.

At 615, the placement of the virtual serving gateway at one or morephysical hosts is determined. An optimization process, such as theexample process described below, may be used to determine the placementof virtual serving gateway(s) at physical host(s).

A set of gateway host candidates may be considered for placing thevirtual serving gateway(s). A gateway host candidate may be any physicalnetwork node (e.g., a server) available in the physical network forhosting a virtual serving gateway. Not all network nodes may be suitablefor hosting a virtual serving gateway (e.g., having insufficient memoryor traffic handling resources). In an extreme case, all network nodes inthe network may be candidates. In the other extreme, there may be onlyone host candidate in the network. The gateway host candidates and theirproperties (e.g., including the current resource usage) may be providedin the network information obtained at 610.

Placement of the virtual serving gateway at physical host(s) may beperformed based on a consideration of the functions and/or resourcesthat the virtual serving gateway is to provide to the UE (e.g., asdefined in the network information), as well any constraints (e.g.,mobility insensitivity) defined in the configuration information. Forexample, where network coding functionality is available at one or morephysical hosts, the virtual serving gateway may be preferentially placedat physical host(s) having network coding and/or video transcodingfunctionality.

Placing the virtual serving gateway at physical host(s) may includeoptimizing placement of the virtual serving gateway at 620. Optimizationof virtual serving gateway placement may include optimizing placementfor content sharing potential. This may be carried out where the inputinformation includes information about the content cached at the hostcandidates and information about content access by the UE. Optimizationfor content sharing potential may be carried out jointly withoptimization for other objectives, such as minimization of operationalcost and/or minimization of network resource utilization.

The virtual serving gateway may be distributively placed across two ormore physical hosts. In such a situation, each physical host may host afraction of the virtual serving gateway and may serve a correspondingfraction of the gateway traffic. For example, consider a virtual servinggateway being fractionally hosted by physical host A and physical hostB, with host A hosting 70% of the virtual serving gateway and host Bhosting 30%. Host A may correspondingly serve 70% of the gateway trafficand Host B may correspondingly serve 30% of the gateway traffic. Where avirtual serving gateway is hosted by a single physical host, it may beconsidered that the physical host is hosting 100% of the virtual servinggateway and serving 100% of the gateway traffic.

In examples where there is freedom to define the functionality(ies)provided by virtual serving gateway(s), the method 600 may includedetermining one or more functionalities (e.g., fountain coding and/orvideo transcoding) that should be provided by one or more virtualserving gateways at one or more physical hosts, such as according toservice requirements set forth in the network information.

At 625, a set of output information defining placement of the virtualserving gateway at one or more physical hosts is generated. The set ofoutput information defining virtual serving gateway placement mayinclude, for example, information associating a UE identifier with agateway-host identifier, hosting percentage, and a service identifier.Where the virtual serving gateway is being placed for a per-service VN(i.e., only one service is being provided) the service identifier may beomitted from the output information.

In some examples, where the method 600 also defines functionality(ies)provided by virtual serving gateway(s) at physical host(s), informationdefining the functionality(ies) to be provided at the physical host(s)may also be outputted. For example, this information may be includedwith the set of the output information at 625, or in a second set ofoutput information. This information may be transmitted to an externalsystem, for example to the SDP system 128.

In some situations, one or more gateway host candidates may not host anyvirtual serving gateway, in which case those gateway host candidateswill not be used in the VN topology.

At 630, the output information may be transmitted for generation of theVN topology and for TE. For example, the output information may betransmitted to the topology generation module 225 of the SDT system 200,and may also be transmitted to the SDN controller 300.

In some examples, the output information may be used by the flowtranslator 310 of the SDN controller 300 to generate flow segments onwhich TE is carried out. In the case where a virtual serving gateway isfractionally hosted across two or more physical hosts, the traffic flowfor that virtual serving gateway may be translated into fractional flowsegments corresponding to fractional hosting of the virtual servinggateway by each host. In this case, high-level flow splitting may takeplace before performing TE, which may provide fine-grained flowsplitting for each fractional flow furthermore.

The example method 600 may be performed by the SDT system 200 inconjunction with TE by the SDN controller 300, to implement aclosed-loop feedback control between the SDT system 200 and the SDNcontroller 300. The VN topology may be thus responsive and adaptive tochanges in network traffic and/or physical network topology. Placementof virtual serving gateways may be performed in consideration of UEmobility, and may be optimized to enable even short-term efficiencies(e.g., content sharing among UEs travelling on the same bus).

Example Optimization Process

An example optimization process that may be used to determine placementof virtual serving gateways at physical hosts is now described. Theexample process may be implemented by the SDT system 200 (e.g., at thegateway placement module 215).

In this example, the following denotations will be used:

U: set of UEs

W: set of gateway host candidates for virtual serving gateways

GW(u): the virtual serving gateway assigned to u, ∀uεU

ε: minimum placement fraction at w, ∀wεW

δ: traffic rate inflation factor at w, ∀wεW

ω: minimum sensitivity of w to UE mobility, ∀wεW

τ: maximum sensitivity of w to UE mobility, ∀wεW

r⁺ _(w): incoming rate upper bound of w, ∀wεW

k_(w): virtual serving gateway count upper bound of w, ∀wεW

r_(u): rate of u, ∀uεU (e.g., statistical rate or device maximum rate)

c_(uw): placement cost of GW(u) at w, ∀uεU, ∀wεW (e.g., hop count)

s_(uw): mobility sensitivity of GW(u) at w, ∀uεU, ∀wεW

p_(uw): placement preference of GW(u) at w, ∀uεU, ∀wεW

a_(uw): placement fraction of GW(u) at w, ∀uεU, ∀wεW

x_(uw): binary indicator of w hosting GW(u), ∀uεU, ∀wεW

b_(w): selection indicator of w, ∀wεW

In the following discussion, the network is modeled with a set of UEs Uconnected to the network G through single-hop connectivity. G includesthe set of physical network nodes N and the edge or link set E. Apre-defined traffic source s, sεN performs downlink communication witheach u, uεU. For example, s may be an ingress router. A subset W of Nare network nodes pre-configured to be virtual serving gateway hostcandidates. For example, network nodes that are suitable gateway hostcandidates may be pre-configured to have larger bandwidth, higher dataprocessing power and/or larger storage space, which may enable thegateway host candidates to accommodate greater traffic, engage inmobility management and/or engage in network coding. W may be equal to Nin some cases. In some examples, s may be included in W.

GW(u) denotes the virtual serving gateway of a given UE u. The two-phasetraffic control mechanism, as discussed above, may be engaged such thatthe downlink traffic for u is directed from s to GW(u) and then fromGW(u) to u. In some cases, the placement of GW(u) may be performed in anintegral manner, meaning that a given GW(u) is hosted by a single nodew, w E W rather than being fractionally distributed across two or morenodes. The cost of the placement of GW(u) at a host candidate w isdenoted as c_(uw), which may reflect any type of cost such asoperational cost, control cost, or combinations thereof, depending onthe cost measure used (e.g., as defined in the configuration informationprovided as input for gateway placement).

In some examples, GW(u) may be distributively placed at multiple hosts,each serving a fraction of traffic passing through GW(u) (this may alsobe referred to as a host hosting a fraction of the virtual servinggateway or the virtual serving gateway being fractionally hosted by eachof the multiple hosts). The placement fraction for a given hostrepresents the placement cost fraction and indicates the fraction of thedownlink traffic for u that is served through the given host,statistically. For example, if w hosts 30% of GW(u) and w′ hosts 70% ofGW(u), then the respective placement costs will be 0.3c_(uw) and0.7c_(uw′); and 30% of the downlink traffic for u will be delivered to wand 70% of the downlink traffic for u will be delivered to w′. Thisapproach may also include the case where GW(u) is placed at a singlehost w, by specifying that w hosts 100% of GW(u).

In this example, each host candidate w is able to implement a networkcoding function (e.g., implementation of fountain coding) forgateway-to-UE communication and/or a transcoding function forgateway-to-UE video data transmission. As a consequence, rate inflation(in the case of fountain coding) or reduction (in the case of videotranscoding) occurs at the gateway host by a factor of δ≧1. In the caseof δ=1, neither transcoding nor network coding is carried out, or thereis no net rate inflation/reduction effect. In the case of δ=0, thegateway host performs no gateway-to-UE communication and serves only toabsorb traffic. Each host candidate w has a rate upper bound r_(w) ⁻ foroutgoing traffic, which may be determined from historical performance,for example. Dividing this upper bound by the rate inflation factor δ,the upper bound of incoming rate of w may be obtained as:

$r_{w}^{+} = {\frac{1}{\delta}{r_{w}^{-}.}}$

It should be noted that r_(w) ⁺ is naturally bounded above by theminimum of total capacity of incoming links incidental to w and that ofoutgoing links. Each w also has a virtual serving gateway count upperbound k_(w), limiting the number of virtual serving gateways (whetherhosted fractionally or integrally) it can host. These properties of eachhost candidate may be specified in the network information provided asinput for gateway placement.

A discussion of what is meant by mobility insensitivity is now provided.First, consider an arbitrary routing path from source s to a UE u. Thepath may be determined according to certain criteria. It may be assumedthat the path length is proportional to the physical distance between sand u. Generally, this is a valid assumption when hop count is used orconsidered as part of the routing criteria. Although this assumption maynot hold in certain specific cases or setups, since the exampleoptimization described here deals with statistical information anddescribes a general solution, this assumption is acceptable. When umoves, the path may change, and the change may occur in a segment of thepath adjacent to u. If u has a high mobility, the changed segment may bea large portion of the path; if u has a low mobility, the changedsegment may be a small portion of the path. A virtual serving gatewaymay be placed in the path as an anchor, which is considered to beinsensitive to (i.e., unchanged by) mobility of u if the routing pathchanges only in the portion downstream of the anchor. In this way, theanchor may serve to “hide” the motion of u from s. Thus, the virtualserving gateway should be placed in such a way as to be insensitive tothe mobility of the respective UE.

The quantification of mobility insensitivity may be understood withreference to the model illustrated in FIG. 7. In this model, the UE u ismoving at a constant speed v_(u). Let d_(uw) denote the distance betweena gateway host candidate w and u's current location. Given a time periodt, the maximum distance that u may move away from its current locationis t×v_(u). In FIG. 7, the dashed circle encloses all possible positionsof u in t. During time period t, the mobility sensitivity of GW(u) at aphysical host w may be represented as:

$s_{uw} = \left\lceil {\frac{t \times v_{u}}{d_{uw}} \times \exp} \right\rceil$

where exp is a scaling factor for precision tuning. Precision tuning maybe carried out because precision is lost in the ceiling operation. Usingthe exp scaling factor, precision loss may be controlled to some extent.The exp scaling factor may be fixed (e.g., as an input parameter) or maybe dynamically determined (e.g., determined on-the-fly by the SDT system200). In the dynamic case, exp may be calculated to be equal to or havethe same magnitude as the median or mean of d_(uw)/(t×u_(v)) values ofall (UE, physical host) pairs, for example. From the above equation, itcan be seen that the larger the value of s_(nw), the greater themobility sensitivity of GW(u).

A discussion of content sharing is now provided. To take intoconsideration the potential for content sharing, consider the examplewhere there is a universal content attribute set. Each piece of contentmay be associated with a subset of attributes. For example, if thecontent comprises a song, the content may be associated with one or moreattributes such as the URL (i.e., the source address), identification ofthe artist, identification of the album, identification of the releasedate, and/or any other suitable attribute. Different types of content(e.g., text, image, video or audio content) may be identified usingdifferent sets of attributes. A piece of content may be uniquelyidentified using its attributes, for example using a hash tag generatedfrom the attributes.

Consider the example where each gateway host candidate w performscontent caching and maintains a local content cache set C_(w). Each UE uis associated with certain content access statistics, described by acontent set C_(u) in which each element i is associated with an accessprobability ρ_(i). The content set may be correlated in time and/orgeography. The statistics information may be collected by the networkusing any suitable mechanism, or may be learned from the UE's historicalbehavior (e.g., in the case where the UE tracks the UE's behavior). Thecontent set accessed by UE u, correlated with time t and location l, isdenoted by C_(u) ^(t,l).

When in-network caching is enabled at gateway host candidates, placementof virtual serving gateways should be optimized to minimize placementun-preference, that is, to maximize the potential that each UE sharesthe content cache(s) at the host(s) of its associated virtual servinggateway in subsequent data sessions. Given time t, the placementpreference factor p_(uw) for each pair of UE and gateway host candidate(u, w) may be represented as:

$p_{uw} = \frac{\sum_{i \in {C_{u}^{t,{L{(u)}}}\bigcap C_{w}^{\rho_{i}}}}}{{C_{u}^{t,{L{(u)}}}\bigcap C_{w}}}$

where L(u) is the set of locations closest to u and C_(u) ^(t,L(u)) isthe union of respective content access sets.

In the example optimization problem discussed here, there are threeoptimization objectives when placing a virtual serving gateway at agateway host candidate. One objective is to minimize the averageplacement cost from a network resource utilization viewpoint, which maybe referred to as the placement cost minimization (PCM) objective.Another objective is to minimize the number of gateway hosts used froman operational cost perspective, which may be referred to as the hostselection minimization (HSM) objective. Another objective is to minimizeplacement un-preference between UEs and respective gateway hosts such asto maximize the content sharing potentials, which may be referred to asthe placement un-preference minimization (PUM) objective. Thus, thisexample PCM-HSM-PUM joint optimization problem may be considered to be acontent-aware gateway placement problem.

The variable a_(uw) is used to represent the fraction of GW(u) placed athost w. The binary variable x_(uw) denotes whether w is hosting afraction of GW(u), and the binary variable b_(w) denotes whether w ishosting any fraction of any virtual serving gateway. The averageplacement cost for placing a virtual serving gateway at a host may berepresented as:

${C(a)} = {\frac{1}{U}{\sum\limits_{w \in W}{\sum\limits_{u \in U}{a_{uw}c_{uw}}}}}$

the total number of hosts selected may be represented as:

${Z(b)} = {\sum\limits_{w \in W}b_{w}}$

and the total placement un-preference may be represented as:

${R(x)} = {\sum\limits_{w \in W}{\sum\limits_{u \in U}{x_{uw}\left( {1 - p_{uw}} \right)}}}$

With a_(uw), b_(w) and x_(uw) being decision variables, the examplemulti-objective optimization problem to achieve PCM, HSM and PUM jointlymay be formulated. The joint optimization may be performed using linearscalarization, where α, β, γε[0,1] are the objective weighting factorssuch that α+β+γ=1.

Because the PCM, HSM and PUM objective values may each be at a differentscale, a scaling factor, when necessary, should be applied to each ofthese objectives to convert their values to the same scale and thereforefacilitate the selection of α, β, γ values. In the following exampleoptimization problem formation, it is assumed that the scaling factor isnot necessary.

The following is the mathematical representation of the examplemulti-objective optimization problem:

$\begin{matrix}{{{\min\limits_{a,b,x,v}{\alpha \; {C(a)}}} + {\beta \; {Z(b)}} + {\gamma \; {R(x)}} + {\mathcal{M}\; v}}{{such}\mspace{14mu} {that}}{{{\sum\limits_{w \in W}a_{uw}} = 1},{\forall{u \in U}}}} & (1) \\{{a_{uw} \leq x_{uw}},{\forall{u \in U}},{\forall{w \in W}}} & (2) \\{{x_{uw} \in \left\{ {0,1} \right\}},{\forall{u \in U}},{\forall{w \in W}}} & (3) \\{{x_{uw} \leq b_{w}},{\forall{u \in U}},{\forall{w \in W}}} & (4) \\{{{ɛ - {a_{uw}x_{uw}}} \leq 0},{\forall{u \in U}},{\forall{w \in W}}} & (5) \\{{{w - {x_{uw}s_{uw}}} \leq v^{w}},{\forall{u \in U}},{\forall{w \in W}}} & (6) \\{{{{x_{uw}s_{uv}} - \tau} \leq v^{\tau}},{\forall{u \in U}},{\forall{w \in W}}} & (7) \\{{{{\sum\limits_{u \in U}{a_{uw}r_{u}}} - r_{w}^{+}} \leq r^{r}},{\forall{w \in W}}} & (8) \\{{{{\sum\limits_{u \in U}x_{uw}} - k_{w}} \leq v^{k}},{\forall{w \in W}}} & (9) \\{v^{w},v^{\tau},v^{r},{v^{k} \geq 0}} & (10)\end{matrix}$

In this example, v=[v^(w), v^(τ), v^(r), v^(k)] is defined as theviolation vector which includes auxiliary variables representing themaximum violations of virtual serving gateway minimum mobilitysensitivity, virtual serving gateway maximum mobility sensitivity,incoming traffic rate, and gateway count upper bound of the hostcandidate, respectively. The last term in the optimization problem is apenalization term, where M a violation penalty matrix and can be set upto penalize different violations differently. Generally, the entries inM should be very large positive values, compared to the possible profitsthat can be obtained in the three minimization objectives.

Constraint (1) above ensures that each virtual serving gateway is fullyhosted. When solving the optimization problem, constraints (2) and (3)together ensure that the binary variable x_(uw) equals to 1 if and onlyif w hosts GW(u) at solution. Constraint (4) ensures that b_(w) atsolution equals to 1 if w is hosting a virtual serving gateway and 0otherwise. Constraint (5) ensures that no placement fraction is smallerthan an allowed minimum fraction, which means that a virtual servinggateway can be distributively placed at a maximum number of physicalhosts and avoids placement fractions that are too small. Constraints (6)to (9) calculate the maximum per host violations. If there are noviolations, v will be a zero vector according to constraint (10). Sinceeach violation is amplified by the very large penalty factor in M, thisexample optimization problem favors a solution that generates zero orminimal violations at the gateway host(s). These constraints may beconsidered to be soft constraints (since violations are permissible).The use of soft constraints rather than hard constraints may enablefeasibility and ensure arrival at an optimal or near-optimal solution.

This example optimization problem is a non-deterministic polynomial-time(NP)-hard mix integer programming problem, where x_(uw), ∀uεU, ∀wεW arethe only (binary) integer decision variables. An example two-stepapproach to solving this problem is now described. In the first step,the problem is relaxed to a linear programming problem and the relaxedproblem is solved to obtain a fractional solution. In the second step,the fractional solution is rounded in an iterative way as follows.First, identify all the UEs with only an integral x_(uw) decision andfix their associated decision values, and sort the remainder set U′ ofUEs (i.e., the set of UEs with a fractional x_(uw) decision). The set U′is sorted by descending order of max_(wεW:x) _(uw) _(<1) x_(uw), ∀uεU′and processed in this order. For processing a UE u, all the decisionvariables related to ∀u′εU′, u′≠u are treated as constant variable andthe PCM-HSM-PUM optimization problem is solved. The decisions are thentaken as the final decision for u. In this example two-step approach,each problem is a linear problem that may be solved using a suitablelinear programming solver such as the GNU linear programming kit (GLPK).

In some examples, the optimization problem may not consider contentsharing, in which case the optimization problem may be simplified byomitting the R(x) objective from the minimization problem set forthabove (i.e., by setting γ=0).

The present disclosure may enable more efficient TE by taking intoconsideration the potential for content sharing between gateway hosts.For example, the present disclosure may take into account UE contentaccess statistics in time and/or location (e.g., statistical informationabout traffic sources accessed by the UE when the UE is near a givengeographical location in a given time period, each source being weightedwith a normalized access rate), gateway host content cache (e.g., usingcontent indexing, such as each content source being weighted with anormalized cache volume), and/or content sharing potential (e.g.,defined as the ratio of the weight of set intersection to the weight orsize of universal traffic source set).

By considering the use of network coding at virtual serving gateways,the present disclosure may help reduce undesirable traffic redundancy atgateways.

When determining virtual serving gateway placement, it may be possibleto selectively base the optimization process either on UE deviceinformation (e.g., the maximum traffic rate supported by the device) orUE statistical information (e.g., traffic statistics by time and/orlocation, such as the average rate when near a given geographicallocation in a given time period). By selecting which type of UEinformation to use for optimization, a more conservative or moreaggressive optimization may be carried out. For example, a conservativeoptimization may be carried out based on a worst case scenario (e.g.,the traffic rate is at the maximum supported by the device) while a moreaggressive optimization may be carried out based on the most likelyscenario (e.g., the traffic rate is at the historical average experienceby the UE for a given location).

The present disclosure also provides a way to quantify the mobilityinsensitivity of a gateway host, and to use mobility insensitivity as aparameter for optimization.

The present disclosure provides certain example algorithms andcalculations for implementing examples of the disclosed methods andsystems. However, the present disclosure is not bound by any particularalgorithm or calculation.

Although the present disclosure describes methods and processes withsteps in a certain order, one or more steps of the methods and processesmay be omitted or altered as appropriate. One or more steps may takeplace in an order other than that in which they are described, asappropriate.

While the present disclosure is described, at least in part, in terms ofmethods, a person of ordinary skill in the art will understand that thepresent disclosure is also directed to the various components forperforming at least some of the aspects and features of the describedmethods, be it by way of hardware components, software or anycombination of the two. Accordingly, the technical solution of thepresent disclosure may be embodied in the form of a software product. Asuitable software product may be stored in a pre-recorded storage deviceor other similar non-volatile or non-transitory computer readablemedium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk,or other storage media, for example. The software product includesinstructions tangibly stored thereon that enable a processing device(e.g., a personal computer, a server, or a network device) to executeexamples of the methods disclosed herein.

In some examples, the present disclosure provides a non-transitorycomputer readable medium having tangibly stored thereon computerexecutable instructions that, when executed by a processing device of aprocessing system, may cause the system to: obtain a set of inputinformation, the input information including: network informationproviding information about a physical network for mobile communicationsby a mobile device; and configuration information providing one or moreparameters for placing a virtual serving gateway, including a mobilityinsensitivity criteria. The instructions may further cause the systemto: determine placement of the virtual serving gateway at one or morephysical hosts in the physical network in accordance with the networkinformation and the configuration information, the virtual servinggateway being distributively placeable across one or more physicalhosts; and generate a set of output information. The output informationmay include: information identifying placement of the virtual servinggateway at the one or more physical hosts; and a respective hostingpercentage for each physical host.

In some examples, the network information may include informationrepresenting cached content stored at each physical host and informationrepresenting content access by the mobile device, and placement of thevirtual serving gateway may be determined based on a determination ofthe potential of the mobile device to access the cached content.

The present disclosure may be embodied in other specific forms withoutdeparting from the subject matter of the claims. The described exampleembodiments are to be considered in all respects as being onlyillustrative and not restrictive. Selected features from one or more ofthe above-described embodiments may be combined to create alternativeembodiments not explicitly described, features suitable for suchcombinations being understood within the scope of this disclosure.

All values and sub-ranges within disclosed ranges are also disclosed.Also, while the systems, devices and processes disclosed and shownherein may comprise a specific number of elements/components, thesystems, devices and assemblies could be modified to include additionalor fewer of such elements/components. For example, while any of theelements/components disclosed may be referenced as being singular, theembodiments disclosed herein could be modified to include a plurality ofsuch elements/components. The subject matter described herein intends tocover and embrace all suitable changes in technology.

1. A logical virtual gateway comprising: a first host comprising aprocessor and a computer readable storage medium for storinginstructions that when executed by the processor cause the first hostto: instantiate a first virtual gateway fractional component; and asecond host comprising a processor and a computer readable storagemedium for storing instructions that when executed by the processorcause the second host to: instantiate a second virtual gatewayfractional component that in conjunction with the first virtual gatewayfractional component provides a logical virtual gateway for associationwith a user equipment, wherein each of the first and second virtualgateway fractional components treats a fraction of traffic associatedwith a user equipment associated with the logical virtual gateway. 2.The logical virtual gateway of claim 1, wherein the logical virtualgateway is a virtual serving gateway.
 3. The logical virtual gateway ofclaim 1, wherein the logical virtual gateways is a virtual user-specificgateway.
 4. The logical virtual gateway of claim 1, wherein the firstand second virtual gateway fractional components serve as anchor pointsfor the user equipment associated with the logical virtual gateway. 5.The logical virtual gateway of claim 1, wherein the traffic associatedwith the user equipment is at least one of uplink and downlink traffic.6. The logical virtual gateway of claim 1, wherein the first host aredistinct physical hosts.
 7. The logical virtual gateway of claim 1,wherein the first host and the second host are virtual entitiesinstantiated upon a common resource pool.
 8. The logical virtual gatewayof claim 1, wherein the first host has access to a first content cacheand the second host has access to a second content cache.
 9. The logicalvirtual gateway of claim 8, wherein the first content cache and secondcontent cache are the same content cache.
 10. The logical virtualgateway of claim 8, wherein content stored by the first content cache isone of the same as, different than and overlapping with, content storedby the second content cache.